File System Translators
By John MacLean
Copyright (c) 1991 Apple Users' Group, Sydney
Republished from Applecations, a publication of the Apple Users' Group, Sydney, Australia.
This article explores File System Translators (FSTs); one of the features of GS/OS that makes it such a fascinating and powerful operating system.
What is a file system?
A file system is the way in which files, directories, boot information, and block allocation information are all arranged on storage media at a block level. Each operating system we have seen in the past has a unique file system with a unique set of features.
For example:
- The DOS 3.3 file system uses the first few tracks for the DOS image, the catalog is held on the central track, and there are no sub-directories.
- The ProDOS file system introduced sub-directories, named volumes, mass storage, and very large files.
- The Macintosh file system supports files with two "forks", a resource fork and a data fork; a feature that has since been added to ProDOS.
- Some operating systems such as unix support multiple level access rights within their file systems.
All of these features require different layouts at a block level, and different catalog and file structures.
What we are accustomed to seeing is the support for the file system being an integral part of the operating system; so that, only DOS 3.3 programs can access DOS 3.3 disks, only ProDOS programs can access ProDOS disks, etc. Sure we have seen programs such as Copy II Plus that can access disks initialised with multiple file systems, but they do not provide a way in which other programs can DIRECTLY access data stored under other file systems.
The Logical File System of GS/OS
The operating system of the Apple IIGS (GS/OS) is the first operating system which makes use of a logical file system. GS/OS does not define where on the disk the catalog should be, how the lists of blocks that make up a file should be structured, or how the block usage should be stored.
The native file system of GS/OS is NOT ProDOS, it has the potential to work equally well with other filesystems. The GS/OS logical file system supports many features which ProDOS does not such as:
- larger than 32K volumes (theoretically hundreds of Gigabytes).
- larger than 32K files (up to four gigabytes).
- Very long filenames with few character restrictions.
In fact, the logical file system of GS/OS was designed to be, wherever possible, a superset of all existing file systems.
What are File System Translators?
File System Translators (FSTs) provide a mapping between the logical file system of GS/OS and the file systems used by other operating systems. Using FSTs, GS/OS applications are completely isolated from the file system in use. In other words, you never need to choose the type of file system you are accessing, it is all handled automatically; in fact, it is likely that you would not even realise what file system is in use.
FSTs allow GS/OS to support multiple file systems at the same time. In other words, with the addition of the appropriate FSTs, GS/OS is capable of reading from and writing to media initialised with any file system.
What benefits do they give?
You will notice under the Finder, and any other GS/OS application that allows you to format and initialise disks, that you have a choice of which file system is used. We are quite used to applications that can read multiple file systems. On the Apple II, Copy II Plus can read ProDOS and DOS 3.3 disks, My own graphics software, The Graphic Exchange (up to version 3.6), can read ProDOS, DOS 3.3, Newsroom, MFS and HFS (Macintosh disks). On the Macintosh, Apple File Exchange can read ProDOS, MFS, HFS, and MS_DOS disks. FSTs take this concept one step further by providing transparent access to multiple file systems for ALL applications that make standard use of the operating system.
If we had a DOS 3.3 FST, there would be no reason why you couldn't write your AppleWorks GS files on a DOS 3.3 volume, and read them back again; AppleWorks GS would not know the difference. You could certainly load your Sandy's Word Processor text files directly into AppleWorks from your DOS 3.3 disks, and your hi-res graphics directly into 816 Paint off your DOS 3.3 disks.
How do FSTs work?
FSTs provide the interface between the high level GS/OS calls and the device driver calls.
There is a definite interface (although at this stage undocumented) between GS/OS and FSTs, and there is another definite interface between FSTs and device drivers (this interface is documented).
Although the details of FSTs are currently undocumented, much can be understood by analysing driver calls, GS/OS calls, the GS/OS reference manual, and the existing FSTs. FSTs basically support each GS/OS call directly, by making calls to the appropriate device driver, and return the relevant information to GS/OS, and thus the application, through the GS/OS parameter block.
For example the VOLUME call for a DOS 3.3 FST would perform the following tasks:
- Calculate the ProDOS block number which contains the VTOC.
- Read in the block into a local buffer.
- Identify the volume as a DOS 3.3 volume by checking key locations.
- Calculate the free space and total space on the volume by analysing the free space bit map.
- Update the GS/OS parameter block with the volume name, free space, and total space.
What FSTs are currently available?
Currently, Apple has provided FSTs to support ProDOS (PRO.FST), character devices (CHAR.FST), CD-ROMs (HS.FST), and AppleShare (APPLESHARE.FST). As it turns out, only a very small proportion of Apple IIGS users have access to CD-ROMs or AppleShare networks, so the only file system the majority of users have access to is ProDOS. In other words, FSTs are fairly useless at present.
What are we likely to see in the future?
It is fairly obvious that the FSTs we are most likely to see introduced in the future are those that aid in data transfers between Macintoshs and Apple IIs. Since we already have an AppleShare FST, it seems likely that if Apple does release further FSTs for the IIGS, they will release an MFS or HFS FST. FSTs for some of the old Apple II file systems, such as DOS 3.3, Apple CPM, and Apple Pascal, would also be welcomed and extremely useful. It may be true that read only versions of these FSTs are released, as this would be sufficient for most users, and much easier to implement.
We are unlikely to get MS-DOS or UNIX FSTs in the near future, as there are currently no device drivers available that can read these file systems at a block level (except for the SCSI drivers). If Apple makes the Superdrive available on the IIGS, or the Applied Engineering 3.5" drive makes reading these disks possible, then we may get these FSTs in the longer term. It is very likely that the number of file systems will eventually decrease, and converge to a single, or a small number of standards. If this does happen, FSTs will make the migration to other file systems painless. For those that have been around Apple //s for a while, imagine what it would have been like if ProDOS programs could have directly accessed data on DOS 3.3 disks at the point when ProDOS was introduced. This is what future file system migrations should be like.
It appears that Apple has realised the importance of data exchange, and file system isolation for the future survival of their machines. I hope they continue their efforts in making FSTs available on the Apple IIGS and the Macintosh line. If they do, it should really help to extend the life of both machines, and make the life of the Apple user much easier.

THIS CONTENT COPYRIGHT © 2007, APPLE MACINTOSH USERS' GROUP, SYDNEY
Permission has been obtained to make this material available on the Internet.

Permission is hereby granted for non-profit user groups to republish this content.
PLEASE CREDIT THE AUTHOR AND THE SOURCE: Applecations, publication of the Apple Users' Group, Sydney, Australia

THIS PAGE COPYRIGHT © 2007, ANDREW ROUGHAN